<html>

<body>

<p align="justify">
This package provides classes which together implement the Open Shortest Path 
First protocol Version 2.
</p>

<p align="justify">
The Open Shortest Path First (OSPF) protocol is an IP link-state
routing protocol, recommended for distributing routing information
among the routers in a single autonomous system (AS), with explicit
support for classless inter-domain routing (CIDR) address allocation.
</p>

<p align="justify">
<code>SSF.OS.OSPFv2</code> is a partial implementation of OSPFv2, based
on the Internet Engineering Task Force's Request for Comments number
2328 (RFC 2328), 
"<a href="http://www.ietf.cnri.reston.va.us/rfc/rfc2328.txt">OSPF Version
2</a>". Currently it only runs on point-to-point networks, because there is
no multicast available. Intended to provide all features of the protocol in 
the future it follows a bottom-up design. On point-to-point networks it has 
been developed beyond the basic features like Hello Protocol, Database Exchange,
Flooding and Shortest Path Calculation. Int<b>ra</b> as well as int<b>er</b> 
area routing are supported and making the interaction with IP more proper, a 
better integration of the protocol into SSFNet was accomplished.
</p>

<p align="justify">
OSPFv2 is <b>NOT compatible to sOSPF</b>. It was completely rebuilt. In comparison to
sOSPF it is much more dynamic, supports multiple areas and maintains a separate 
area data structure for each area the router is connected to. Every area structure 
supports its own Link State Database, which is able to store Router as well as Summary
Type 3 and 4 LSAs. Version 0.2.2 is therefore able to deal with stub areas and
AS boundary routers, but it still does not process external route information 
like sOSPF.
</p>

<p align="justify">
OSPFv2 is a dynamic version of OSPF. But because of the absence of multicast it is
not able to detect neighbors dynamically. It retrieves the addresses directly
from the underlying link layer and then performs the discovery process 
simulating multicast by unicast. But this is the only exception to its dynamic
behavior. <br>
Having dicovered a neighbor, periodically sendig of Hello Packets guarantees
neighbor maintenance. Thereafter the Database Exchange process synchronizes
the LS Databases of both routers using Database Description, Link State
Request and Link State Update Packets as determined by the RFC. The Flooding
Procedure ensures continuation of the synchronization process when state
EXCHANGE in neighbor relation is reached. All these processes are triggered by
the neighbor state machine whose functionality is mainly implemented in class 
Neighbor. Its logic is triggered by method <code>OSPF.push()</code> every time
a new OSPF packet arrives. Packets containing LSA updates are sent in intervals
coordinated by a <code>PacingTimer</code> in class <code>Interface</code>. <br>
A shortest path tree is built from the Router LSAs of all Databases. Thereafter,
inter-area routes are computed and, on area border routers, Summary LSAs are
created and originated. <br> 
Periodically reoriginating of selforiginated LSAs, aging of LSAs and time 
blocks for the installation process thereby ensure an OSPF like behavior.
Eventually an OSPF Routing Table is built from the tree and the inter area routes
and used to update the IP Forwarding Table. These Rouing Table calculations are
scheduled by the <code>RTCControlTimer</code> in class <code>OSPF</code>. The
timer is configurable via the attributes <code>spf_delay</code> and <code>spf_hold_time</code>.
</p>

<p align="justify">
Because in version 0.2.2 inter-area routing is employed, the routing table of an
OSPFv2 router now provides shortest paths to all reachable
</p>

<li><b>stub networks within an AS</b> (only point-to-point!)</li>
<li><b>area border routers in the router's attached areas</b></li>
<li><b>AS boundary routers in the AS in case the router is not placed in a stub area</b>

<p align="justify">
This release has been tested by a partially implemented test suite developed
by the Inter Operability Lab at University of New Hampshire. Not all of the 
tests get a PASS because OSPFv2 is still under development and it can't make
use of multicast to send packets to the correct address.<br>
For further information concerning the test suite design  see documentation in 
<code>ssfnet/src/SSF/OS/OSPFv2/test/doc/index.html</code> 
</p>

<p>
<b>Further Information</b> about OSPFv2 and its configuration: See 
distribution file
<code>ssfnet/src/SSF/OS/OSPFv2/doc/index.html</code>.
</p>

</body>

</html>
